home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 618 < prev    next >
Encoding:
Text File  |  1996-08-06  |  4.0 KB  |  119 lines
  1. Path: chronicle.mti.sgi.com!austern
  2. From: Roman Lechtchinsky <wolfro@cs.tu-berlin.de>
  3. Newsgroups: comp.std.c++
  4. Subject: Hiding Overloaded Functions
  5. Date: 04 Mar 1996 10:20:46 PST
  6. Organization: Technical University of Berlin, Germany
  7. Approved: austern@isolde.mti.sgi.com
  8. Message-ID: <4h9psh$fnv@news.cs.tu-berlin.de>
  9. NNTP-Posting-Host: isolde.mti.sgi.com
  10. X-Original-Date: 2 Mar 1996 15:35:45 GMT
  11. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  12.     iQBVAwUBMTs0qky4NqrwXLNJAQHugAH/e79ZJCkXwq0s2BBhKbfu3s3i69q+kWT/
  13.     ynk1zQCwSiUMiwPnaF3oJL0wV/9BXbLN4EOun4sb2AIklqUpoANIUA==
  14.     =FZyl
  15. Originator: austern@isolde.mti.sgi.com
  16.  
  17. Hi everybody,
  18.  
  19. I don't know what happened to my previous article on this topic so I've 
  20. rewritten it and now I'll try it again.
  21.  
  22. In the present standard as well as in the April draft, there exists one 
  23. rule which I don't like at all. Basically, the concept is that if several 
  24. overloaded functions are defined in a class A and one of these functions 
  25. is redefined in a derived class B this function hides all functions 
  26. inherited from A that have the same name:
  27.  
  28. class A
  29. {
  30. public:
  31.  void    foo();
  32.  void    foo( int );
  33. };
  34.  
  35. class B : public A
  36. {
  37. public:
  38.  void    foo();    // void foo(int) is hidden; use A::foo(int)
  39. };
  40.  
  41. I don't understand why this rule has been invented. It seriously affects 
  42. the concepts of reusability and encapsulation. In fact, imagine A is 
  43. defined in a class library and B is a class a user created which requires 
  44. foo(void) to be reimplemented but still wants to use foo(int). Of course 
  45. one can use a qualifier to access the hidden function; however, you have 
  46. to know in which class the function has been declared then. This is not 
  47. difficult in the above example; in a class library with a deep inheritance 
  48. tree this is more than inconvenient. Things get even worse when dealing 
  49. with virtual functions. Virtual functions are an excellent way to define a 
  50. behaviour which might ( but must not ) be altered in more special classes 
  51. ( this is not all what virtual functions can do but it is an essential 
  52. part ). A great advantage of this mechanism is that you do not have to 
  53. know exactly in which class the behaviour is defined: you simply use it or 
  54. alter it. Now consider the following example:
  55.  
  56. class A
  57. {
  58. public:
  59.  virtual    void foo();
  60. };
  61.  
  62. class B : public A
  63. {
  64. public:
  65.  virtual    void foo( int );
  66. };
  67.  
  68. class C1 : public B
  69. {
  70. public:
  71.  virtual    void foo();
  72. };
  73.  
  74. class C2 : public B
  75. {
  76. public:
  77.  virtual    void foo();
  78. };
  79.  
  80. int 
  81.  
  82. I don't think it is too far-fetched.
  83. A solution could be that the developer redeclares all overloaded functions 
  84. in every class where at least one of them has to be redeclared. Why should 
  85. he have to do so? If you create a derived class you expect it to have the 
  86. entire functionality of the base class; usually you simply want to extend 
  87. this functionality or somehow specialise it but you do not expect that a 
  88. member function cannot be called directly just because you redeclared 
  89. another member function. This is simply not OOP. 
  90. In fact, the April draft is contradictory here. It says:
  91.  
  92.   Members of  a  class  are  data  members,  member functions, nested
  93.   types, and member constants (9.2.1),
  94.  
  95. and then later:
  96.  
  97.   Unless  redefined  in  the derived class, members of a base class can be     
  98.   referred to  in  expressions  as  if  they were members of the derived   
  99.   class (10.1).
  100.  
  101. Now, if I redefine an overloaded function I certainly do redefine a 
  102. member. However, it is only one member I redefine so why am I not able to 
  103. access other members I have not redefined? What I really miss in the draft 
  104. is a definition like: "Functions are uniquely identified by their name and 
  105. their parameter declaration" ( it's not perfect, I know ). To me, this 
  106. would make the concept of the language clearer and the language itself 
  107. easier to use.
  108.  
  109. Bye
  110.  
  111. Roman
  112. ---
  113. [ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
  114.                 newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  115.   comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  116.   Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  117.   Comments? mailto:std-c++-request@ncar.ucar.edu 
  118. ]
  119.